Dell Recovery Manager for Active Directory Forest Edition is a product that can be employed to recover an Active Directory forest or specific domains in the forest in response to corruption or improper modification to the forest. Recovery Manager can automate the various manual tasks involved in a recovery, remotely quarantine corrupt domain controllers, and restore domain controllers to speed up the overall recovery and restore business operation quickly.
The process of recovering an Active Directory forest can be extremely complicated. For example, Microsoft outlines over a dozen steps just to get a domain controller up and running. These steps include quarantining domains, seizing operations master roles, metadata cleanup, DNS configuration, and resetting many Active Directory account passwords, among many others that must be performed on each domain controller in the forest. If these steps are performed incorrectly or out of order, the recovery process may need to be restarted from the beginning.
Recovery Manager facilitates this recovery process by automating the various steps thereby ensuring that they are completed correctly and in order. To employ Recovery Manager or other Active Directory recovery solutions, it is typical to prepare a “disaster recovery plan” which defines the steps that the recovery solution should perform. Then, if a disaster occurs, Recovery Manager can execute the steps of the disaster recovery plan to quickly restore a domain or forest.
In an Active Directory environment, a domain controller functions to authenticate users and to enforce security policy within a domain. Key components of the domain controller are therefore the authentication mechanisms employed to provide these functions. Currently, a domain controller may typically implement the NTLM (NT LAN Manager) and/or Kerberos authentication protocols. As an overview, in a typical scenario, a user will enter his or her credentials on a client computer that is part of an Active Directory domain causing an authentication provider on the client computer to commence an exchange with the domain controller to thereby authenticate the user on the domain (as opposed to authenticating the user on a local account). This exchange may be carried out using NTLM or Kerberos. As part of this exchange, the client may receive a ticket/token (e.g., a Kerberos TGT (ticket-granting ticket)). Then, when the client attempts to access a service or resource within the domain, the client can present this ticket/token to the domain controller for validation again using NTLM or Kerberos. If the domain controller validates the ticket/token, the client will be allowed to access the desired service or resource. Accordingly, without a functioning domain controller, a user will be unable to login to a Windows system and will be unable to access services or resources within the domain.
During an Active Directory disaster (which may occur for various reasons such as when Active Directory objects are accidentally or intentionally deleted), these authentication mechanisms may not be operational. For example, when a disaster occurs, an administrator may oftentimes boot the failed domain controller (or more particularly, the server that was functioning as a domain controller) into the Directory Services Restore Mode (DSRM). In DSRM, Active Directory is not started on the server and the object database remains offline thereby allowing specific objects to be restored. When in DSRM, Kerberos is not available. Also, in many cases, NTLM is disabled on the domain controller for security reasons (e.g., because Kerberos provides stronger authentication than NTLM).
Recovery Manager employs a client/server architecture to protect domain controllers and to provide centralized backup/restore management as is represented in FIG. 1. In this client/server architecture, a recovery console 101 may be executed on any suitable computing device and a recovery agent 103 may be installed on each domain controller 102a-102d that is to be managed in the forest (i.e., on any domain controller that will be part of the disaster recovery plan). Although four domain controllers are depicted in FIG. 1, any number of domain controllers could be managed/protected by Recovery Manager. In the following description, any of these domain controllers can be generally referred to as domain controller 102.
Recovery agent 103 is tasked with performing various backup and restore operations and should therefore be accessible when the domain controller is in DSRM. An administrator can employ recovery console 101 to communicate with recovery agent 103 in the event of a disaster to perform any appropriate restore operations (e.g., resetting passwords, managing Flexible Single Master Operation (FSMO) roles, raising the relative ID (RID) pool, etc.). Recovery console 101 can also communicate with recovery agent 103 at other times. Typically, recovery console 101 and recovery agent 103 will be configured to communicate using Remote Procedure Call (RPC).
Since recovery agent 103 will be capable of performing administrative tasks on the domain controller, recovery console 101 and recovery agent 103 can be configured to authenticate prior to communicating. This will ensure that only an authorized user of recovery console 101 can communicate with recovery agent 103 (i.e., that recovery agent 103 will not be accessible to a malicious application). This will also allow recovery console 101 to verify that it is connecting to recovery agent 103 and not to an impersonating application.
Recovery console 101 and recovery agent 103 can typically be configured to employ the Microsoft Negotiate Security Support Provider (SSP) to perform mutual authentication. The Microsoft Negotiate SSP negotiates between using NTLM or Kerberos. Under normal conditions, one or both of NTLM and Kerberos will be available for authentication purposes. However, as mentioned above, when the domain controller is in DSRM, Kerberos will not be available. Therefore, if the domain controller has been configured to disable NTLM, no authentication mechanism will be available. In such scenarios, because recovery console 101 and recovery agent 103 are configured to require mutual authentication, they will be prevented from communicating.